From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: <9FAD7E5EBDD14B4981E81E66FA62E5C70518B291B3@nubula-vm2> Possibly related was something I mentioned a few days back. I have noticed that when I close a Serial port on Windows (XP-32 is my test system) that it can take up to two seconds. Often it returns in just a few milliseconds however. I have never been able to determine a pattern. Since my open operations occur on a different thread, it was possible for me to re-open in a second thread before the first thread had come back from the close(). In that situation , the second thread could even use the port for a while before the first thread finally acted to close it, cutting of the second thread midstream. Ah the joys of multi-threading. Now I have a flag that reports a pending "close" operation by any thread. Only when that has cleared is it safe to re-open. > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of > Kustaa Nyholm > Sent: Friday, February 03, 2012 4:06 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Slow detection of serial ports > > Hi, > > I've got no direct answer to your question but in developing my > PureJavaComm > I came across the fact that trying to open 'busy' port in Windows can take > up to nine seconds. And there was nothing I could do to work around that. > This maybe related issue...or not. YMMV > > cheers Kusti > > > On 2/3/12 13:42, "Matthes R." wrote: > > >I forgot to mention that the slow part is somewhere inside the > >CommPortIdentifier.getPortIdentifiers() method. Everything else works > >quite fast. > >Best, > >Matthes > > > >2012/2/3 Matthes R. > > > >Hi all, > > > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. > >Everythings works like a charm there. Now, I wanted to test my > >application on a Windows 7 64bit system and observed really long startup > >time of RXTX comm port detection. I am using the following code to search > >for open serial ports. It taks like 20 seconds to go through all > >registered ports. Anybody ever observed such behavior and knows how to > >fix it? > > > >Thanks in advance, > >Matthes > > > >private void initiliaze() throws Exception { > > boolean found = false; > > > > /* > > * the global ports of the OS > > */ > > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > > > CommPortIdentifier portId = null; > > int c = 0; > > while (portList.hasMoreElements()) { > > c++; > > portId = (CommPortIdentifier) portList.nextElement(); > > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > > > if (portId.getName().equals(this.preferredPort)) { > > if (this.log.isInfoEnabled()) { > > this.log.info ("Using port: > >"+this.preferredPort); > > > > } > > found = true; > > } > > try { > > this.openPorts.put(portId.getName(), (SerialPort) > > portId.open("MK Com Handler " + portId.getName(), > >2000)); > > > > } > > catch (PortInUseException e) { > > } > > } > > } > > > > if (!found) { > > throw new Exception("Port " + this.preferredPort + " not found."); > > > > } > > > > /* > > * open the port > > */ > > this.serialPort = this.openPorts.get(this.preferredPort); > > if (this.serialPort == null) { > > this.log.warn("Could not open port "+ this.preferredPort); > > > > return; > > } > > > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > > SerialPort.STOPBITS_1, > > SerialPort.PARITY_NONE); > > > > this.serialPort.notifyOnDataAvailable(true); > > > > this.serialPort.notifyOnOutputEmpty(false); > > > > this.inputStream = this.serialPort.getInputStream(); > > this.outputStream = this.serialPort.getOutputStream(); > > > > this.byteBuffer = new ByteArrayOutputStream(); > > > > > > this.serialPort.addEventListener(this); > >} > > > > > > > > > > > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Feb 3 19:16:26 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 3 Feb 2012 19:16:26 -0700 (MST) Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On Fri, 3 Feb 2012, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > Hi Matthes, One thing I have observed is that enumerating ports can be drastically slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 seconds to find out what devices are in the area. The drivers often have an option to expose the Bluetooth device as a traditional serial port which can then result in triggering a Bluetooth scan. -- Trent Jarvi tjarvi at qbang.org From bhumika2006 at gmail.com Sun Feb 5 17:00:33 2012 From: bhumika2006 at gmail.com (Bhumika Malik) Date: Sun, 5 Feb 2012 19:00:33 -0500 Subject: [Rxtx] Cannot Compile rxtx Message-ID: Compilation of RXTX presents several missing files, e.g. config.h, etc. I am not able to build my Java program even after copying the relevant files RXTXComm.jar, and the .dll's to the JDK installation. Please guide. Bhumika -------------- next part -------------- An HTML attachment was scrubbed... URL: From onurakdemir1 at gmail.com Mon Feb 6 01:49:49 2012 From: onurakdemir1 at gmail.com (onur akdemir) Date: Mon, 6 Feb 2012 10:49:49 +0200 Subject: [Rxtx] write failure Message-ID: Hi , I try to open a serialport - which has no target device attached- and write some bytes to it . But it waits on write function , no timeouts , nothing!! Is this a known bug ? I have searched in mailing list archive . Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Mon Feb 6 02:44:54 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Mon, 6 Feb 2012 09:44:54 +0000 Subject: [Rxtx] write failure In-Reply-To: References: Message-ID: I wouldn't be surprised if that is "expected behaviour" for such a scenario. On Win32 at least, RXTX simply asks the underlying operating system to write the bytes and waits for a response of "yes, that's completed for you" or "that didn't work" -- see serial_write() function in termios.c. If Windows, or more importantly the device driver for a virtual serial port, doesn't raise an appropriate error or response then it will sit and wait. It would be useful to have a write timeout and it is quite easy to implement with the current code but then you just have to deal with that situation and somehow recover the offending port. I've had this trouble with some bad virtual serial port drivers and it can be sufficient to interrupt the thread that's doing the write if it's been stuck there for an excessive period (of course that is some factor of the baud and amount of data sent for write). Regards, Michael Erskine From Martin.Oberhuber at windriver.com Mon Feb 6 05:04:03 2012 From: Martin.Oberhuber at windriver.com (Oberhuber, Martin) Date: Mon, 6 Feb 2012 12:04:03 +0000 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: References: <146B1557584B0B4DBD25ABAD45EF70F01FBFF17C@ALA-MBB.corp.ad.wrs.com> Message-ID: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Hi Kusta, FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 (attached) and it looks like the IBM JVM actually does use some shared memory mechanism in order to do CommPortOwnership events across JVM instances. I don't think this changes anything conceptually - I still believe that this is not a must have - but I did find it interesting that somebody actually does it. Cheers Martin -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Monday, January 23, 2012 6:14 PM To: rxtx at qbang.org Subject: Re: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? On 1/23/12 11:39, "Oberhuber, Martin" wrote: Hi Martin, thanks for a very informative answer. So my conclusion is that in this respect JavaComm,RXTX and PureJavaComm all perform the same and there is no need to try to 'improve' this. Good, let's keep it that the way it is. cheers Kusti >Hi Kustaa, > >At Eclipse, we're running inside a single VM but multiple plugins >(which may not know anything about each other) can be installed by the end user. >In this situation, it is possible the different plugins may want access >to the serial port, and we're using the CommPortOwnershipListener in >order to cleanly give up access if some other plugin wants it. > >For example, in our commercial offering on top of Eclipse, a serial >terminal can own the port most of the time; but we also have a wizard >(in a different plugin) which can automatically retrieve settings from >an embedded target, and a higher connection layer (yet another plugin) >which can exchange data over the serial line. > >In the past, when a port was owned by eg the Terminal and another >plugin wanted access, we allowed the user to grant or disallow the >request; but that never worked well since multiple dialogs were stacked >on top of each other. Our new workflow is that a plugin which wants >access to a port that's currently owned by a different plugin asks the >user whether it's OK to steal the port; any currently owning plugin >releases the port without further notice. More rationale for this >workflow decision is documented on Eclipse Bugzilla 221184 [1]. > >So in my opinion, the only use of CommPortOwnershipListener is clean >shutdown of a port-owning system when the port is requested ("stolen") >by somebody else. For reference, the code of our Eclipse Terminal is >available in Open Source here [2] at line 71 ff, and here [3] at line >146 ff (polite question whether the port should be stolen) and line 163 >ff (actually stealing the port). > >Now, regarding your concrete questions ... > >1. Yes there is some sense using CommPortOwnershipListener inside a >single VM and we use it > >2. Sun JavaCom works exactly the same as RXTX (after I actually fixed a >couple of bugs in RXTX several years back) > >3. Trying to make it work across VM's doesn't make sense just like >stealing a port from a native app doesn't make sense... the best you >can do is a dialog showing / identifying the app that currently holds >the port, such that the user can manually close that other app; note >that in this case, the user can switch to the other app for closing it, >which may not always possible if there's multiple clients / plugins >inside a single componentized system like Eclipse, Netbeans or similar > >4. One potential problem that a componentized system may have is if one >component uses JavaComm and the other is using RXTX ... then these two >can't talk to each other. IMO another reason why trying to allow your >PureJavaComm work across multiple VM's doesn't make sense IMO. > >Cheers, >Martin > >[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=221184 > >[2] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialPortHandler.java?view=markup&root=Tools_Project > >[3] >http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.tm.core/terminal/ >org >.eclipse.tm.terminal.serial/src/org/eclipse/tm/internal/terminal/serial >/Se rialConnectWorker.java?view=markup&root=Tools_Project > > >-----Original Message----- >From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf >Of Kustaa Nyholm >Sent: Thursday, January 19, 2012 4:28 PM >To: rxtx at qbang.org >Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone >using it? > >Marcin's recent postings brought back an old issue/question I have: > >What is the use of CommPortOwnershipListener? > >Cursory look inside RXTXT source code suggests that it only works >within the single JVM instance, which seems to make it pretty useless >or at least unnecessary as surely if anyone needs it they could wrap >their own just as easily. > >I had a cursory look at the JavaComm javadoc and did not found any >definitive answer if it should work across JVMs or not. >I seem to remember that previously I had inferred from the javadoc that >it works by definition only within a single application. > >Nor could I found out if JavaComm CommPortOwnershipListener actually >works or not accross JVMs. > >Also it seem pretty much ambitious to make this work between Java and >native applications not to mention between different users/sessions in >a shared box. > >So is anyone actually using this and if so why? > >Does JavaComm work any 'better' than RXTX in this respect? > >I'm mainly interested in this as my PureJavaComm works the same way as >RXTX and I was sort of wondering if I should try to improve this aspect >for more conformance to JavaComm or not... > >To make it work across different JVM instances and user sessions I >guess something based on sockets/local loopback could be hacked >together but this would probably have its own issues such as port conflicts etc. > >Seems like a lot of work and potential failure points for a pretty >useless feature if you ask me...or maybe I'm not seeing this clearly... > > >cheers Kusti > > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An embedded message was scrubbed... From: "Oberhuber, Martin" Subject: Re: [Rxtx] Port locking on Linux (lockfiles) Date: Mon, 1 Sep 2008 15:36:31 +0000 Size: 6851 URL: From Kustaa.Nyholm at planmeca.com Mon Feb 6 05:44:27 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 6 Feb 2012 14:44:27 +0200 Subject: [Rxtx] CommPortOwnershipListener in JavaComm / RXTX anyone using it? In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC9120A@ALA-MBB.corp.ad.wrs.com> Message-ID: On 2/6/12 14:04, "Oberhuber, Martin" wrote: >Hi Kusta, > >FYI today by chance I ran into a very old E-Mail from 1-Sep-2008 >(attached) and it looks like the IBM JVM actually does use some shared >memory mechanism in order to do CommPortOwnership events across JVM >instances. > >I don't think this changes anything conceptually - I still believe that >this is not a must have - but I did find it interesting that somebody >actually does it. > >Cheers >Martin Hi Martin, thanks for remembering my inquiry! Very interesting information indeed, thanks for digging this up and sharing. I agree with you that this is not a must have and thus I plan no changes for this (in PureJavaComm) for the time being. br Kusti From d.irwin at delcan.com Tue Feb 7 15:36:59 2012 From: d.irwin at delcan.com (David Irwin) Date: Tue, 7 Feb 2012 16:36:59 -0600 (CST) Subject: [Rxtx] Missing 0xFF data and serial port resetting Message-ID: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> All, I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi EtherLight (IP-to-serial terminal server with their RealPort serial driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've found that when a 0xFF is sent by an attached serial device and received by our application that the 0xFF is missing in the response along with some surrounding bytes. This only happens in a Linux environment; using the same Java application/rxtx driver/Digi EtherLight device in a Windows XP environment and it works fine.? One suggestion that we tried was to turn off the serial port's inpck flag (strip parity bit) which seems like it would solve our problem (refer to this Digi post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well as this previous RXTX mailing list post that had a similar issue: http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). However it turns out that for some reason the inpck flag always gets reset whenever we use the RXTX serial driver. See below for a before and after snapshot of the serial port's status: before: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke after: ditty-rp -a < /dev/ttyS4 onstr \033[5i offstr \033[4i term ansi maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace DTR+ RTS+ CTS- CD- DSR- RI- startc = 0x11 stopc = 0x13 -aixon astartc = 0x0 astopc = 0x0 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke We've also tried using the later rxtx-2.2pre2 driver with the same result. Is there anything that we can do to prevent this parity bit flag from being reset when used with RXTX? Anything that I can look at to further debug this on our end? Any other suggestions? Thanks, Dave ____ This communication may contain information that is confidential, privileged or subject to copyright. If you are not the intended recipient, please advise by return e-mail and delete the message and any attachments immediately without reading, copying or forwarding to others. From tjarvi at qbang.org Wed Feb 8 08:20:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 8 Feb 2012 08:20:39 -0700 (MST) Subject: [Rxtx] Missing 0xFF data and serial port resetting In-Reply-To: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> References: <00e001cce5e9$00f33020$02d99060$@irwin@delcan.com> Message-ID: On Tue, 7 Feb 2012, David Irwin wrote: > All, > > I'm using the rxtx-2.1.7 RXTX serial driver in combination with a Digi > EtherLight (IP-to-serial terminal server with their RealPort serial > driver) in RHEL 5.3 (2.6.18-128.e15) using Sun/Oracle JDK 1.5.0_18. We've > found that when a 0xFF is sent by an attached serial device and received > by our application that the 0xFF is missing in the response along with > some surrounding bytes. This only happens in a Linux environment; using > the same Java application/rxtx driver/Digi EtherLight device in a Windows > XP environment and it works fine.? > > One suggestion that we tried was to turn off the serial port's inpck flag > (strip parity bit) which seems like it would solve our problem (refer to > this Digi > post:?http://forums.digi.com/support/forum/printthread_thread,9376 as well > as this previous RXTX mailing list post that had a similar issue: > http://mailman.qbang.org/pipermail/rxtx/2010-December/9363323.html). > However it turns out that for some reason the inpck flag always gets reset > whenever we use the RXTX serial driver. See below for a before and after > snapshot of the serial port's status: > > before: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk -inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > after: > > ditty-rp -a < /dev/ttyS4 > onstr \033[5i offstr \033[4i term ansi > maxcps 100 maxchar 50 bufsize 100 edelay 100 -forcedcd -altpin -fastbaud > (9600) -printer -rtstoggle -rtspace -dtrpace -ctspace -dsrpace -dcdpace > DTR+ RTS+ CTS- CD- DSR- RI- > startc = 0x11 stopc = 0x13 > -aixon astartc = 0x0 astopc = 0x0 > speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase > = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; > start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; > flush = ^O; min = 0; time = 100; -parenb -parodd cs8 -hupcl -cstopb cread > clocal -crtscts -cdtrdsr -ignbrk -brkint -ignpar -parmrk inpck -istrip > -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost > -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop > -echoprt -echoctl -echoke > > We've also tried using the later rxtx-2.2pre2 driver with the same result. > Is there anything that we can do to prevent this parity bit flag from > being reset when used with RXTX? Anything that I can look at to further > debug this on our end? Any other suggestions? RXTX does two heavy handed configurations that are probably what you observe. These have been in RXTX since possibly the first release. While finding available ports, RXTX calls cfmakeraw(). This happens when a serial port is opened in RXTX (SerialImp.c). cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available charac- ter by character, echoing is disabled, and all special process- ing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; Thats probably OK in your case. Once the ports are enumerated and a port is opened for IO, another change is made: int configure_port( int fd ) { struct termios ttyset; if( fd < 0 ) goto fail; if( tcgetattr( fd, &ttyset ) < 0 ) goto fail; ttyset.c_iflag = INPCK; <==== Looks like it fits. ttyset.c_lflag = 0; ttyset.c_oflag = 0; ttyset.c_cflag = CREAD | CS8 | CLOCAL; ttyset.c_cc[ VMIN ] = 0; ttyset.c_cc[ VTIME ] = 0; It should be possible to change the setting with stty like programs after opening the port for test purposes. I assume these settings are based upon what other serial port software does. If you want to change the INPCK setting, it will probably require recompiling RXTX for Linux. -- Trent Jarvi tjarvi at qbang.org From pgallen at gmail.com Fri Feb 10 12:58:07 2012 From: pgallen at gmail.com (Paul G. Allen) Date: Fri, 10 Feb 2012 11:58:07 -0800 Subject: [Rxtx] Errors when using rxtx Message-ID: I D/L pre-compiled binaries and installed as per the instructions. I am using JDK 1.6.0-14. My application was using the Sun COMM API on Windows XP, but due to many Windows COM errors (COM ports dropping out and re-appearing again) as well as wanting to upgrade to Windows 7 soon, I am attempting to use rxtx now. When I run my application, the first issue is the slow init. I understand rxtx scans all ports and I have anywhere from 8 to 20. It would be nice to mitigate this, but it's not a show stopper. The real problem is a recurring error whenever a port is disconnected and reconnected (done several times by the application). In every case, I get this error: Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): The parameter is incorrect. Almost forgot, I am using rxtx 2.1-7: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Anyone have any idea? Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com From Kustaa.Nyholm at planmeca.com Fri Feb 10 14:20:17 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 10 Feb 2012 23:20:17 +0200 Subject: [Rxtx] Errors when using rxtx In-Reply-To: Message-ID: On 2/10/12 21:58, "Paul G. Allen" wrote: > >Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): >The parameter is incorrect. Well, you could dig into the source code, add some debug printouts and see what the problem is in detail. Also you might want to try this, even if it turns out it does not solve your issues it is at east many times easier to debug as this is pure java with not C-code in sight: http://www.sparetimelabs.com/purejavacomm/index.html cheers Kusti From tjarvi at qbang.org Fri Feb 10 13:11:54 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 10 Feb 2012 13:11:54 -0700 (MST) Subject: [Rxtx] Errors when using rxtx In-Reply-To: References: Message-ID: On Fri, 10 Feb 2012, Paul G. Allen wrote: > I D/L pre-compiled binaries and installed as per the instructions. I > am using JDK 1.6.0-14. My application was using the Sun COMM API on > Windows XP, but due to many Windows COM errors (COM ports dropping out > and re-appearing again) as well as wanting to upgrade to Windows 7 > soon, I am attempting to use rxtx now. > > When I run my application, the first issue is the slow init. I > understand rxtx scans all ports and I have anywhere from 8 to 20. It > would be nice to mitigate this, but it's not a show stopper. > > The real problem is a recurring error whenever a port is disconnected > and reconnected (done several times by the application). In every > case, I get this error: > > Error 0x57 at /home/bob/foo/rxtx-devel/build/../src/termios.c(2352): > The parameter is incorrect. > > Almost forgot, I am using rxtx 2.1-7: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Anyone have any idea? Hi Paul, This is rxtx trying to set the comm port up: if ( !SetCommState( index->hComm, &dcb ) ) { report( "SetCommState error\n" ); YACK(); return -1; } With multiple ports opening and closing, I'm wondering if this isnt a bug we found involving the index linked list. If thats the case, closing a second port in three that have been opened and reopening it would cause problems like you observe. Basically, index->hComm would have invalid data. If thats the case, the 2.2pre binaries should help you. http://rxtx.qbang.org/pub/rxtx/rxtx-2.2pre2-bins.zip Another possibility is the underlying call failed because a virtual serial port needed time before being reopened and setup. Bluetooth is an example that can have complicated stacks under what appears as a simple serial port that comes and goes often. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Thu Feb 16 01:20:32 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Thu, 16 Feb 2012 09:20:32 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: Hi all, sorry for the late reply. I had some other stuff to take care of. But now I tried to realize all your hints and *tada*: Trent, you were right. It was the Windows bluetooth stack which slowed down the whole startup thing alot. When disabled, RTXT initializes as fast as on Linux systems. Thanks for all your help, much appreciated! Best Regards, Matthes 2012/2/4 Trent Jarvi > > > On Fri, 3 Feb 2012, Matthes R. wrote: > > Hi all, >> >> I am using RXTX 2.2pre1 for quite a while one Linux systems now. >> Everythings works like a charm there. Now, I wanted to test my application >> on a Windows 7 64bit system and observed really long startup time of RXTX >> comm port detection. I am using the following code to search for open >> serial ports. It taks like 20 seconds to go through all registered ports. >> Anybody ever observed such behavior and knows how to fix it? >> >> > Hi Matthes, > > One thing I have observed is that enumerating ports can be drastically > slowed down by Bluetooth virtual serial ports. Bluetooth takes about 10 > seconds to find out what devices are in the area. > > The drivers often have an option to expose the Bluetooth device as a > traditional serial port which can then result in triggering a Bluetooth > scan. > > -- > Trent Jarvi > tjarvi at qbang.org > > ______________________________**_________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/**mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Thu Feb 16 16:43:20 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Thu, 16 Feb 2012 23:43:20 +0000 Subject: [Rxtx] Licensing Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. Can someone from the RXTX comment on the inconsistency? Which is authoritative? Thanks. Steve Cohen Technical Architect AT&T Relay Services From jfh at greenhousepc.com Thu Feb 16 17:28:30 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Thu, 16 Feb 2012 17:28:30 -0700 Subject: [Rxtx] Licensing Message-ID: <20120216172830.8ef0e5b4a80cef441275a6330ffad77d.2fcafe113f.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Thu Feb 16 16:07:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:07:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > I have read the licensing pages on RXTX (http://rxtx.qbang.org/wiki/index.php/License and http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, downloaded from the same site http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the license is the GPL, not the LGPL. For example, the README file within that zip and many if not all of the files in the source directory indicate a GPL license. > > Can someone from the RXTX comment on the inconsistency? Which is authoritative? > Hi Steve, The license is LGPL 2.1 with an exception for users of Sun's CommAPI which allows linking over a 'controlled interface' which was recommended and approved by a few companies. http://users.frii.com/jarvi/rxtx/license.html There are no plans for making any changes to the license. I'll try to find and correct any inconsistancy you found. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Feb 16 16:28:07 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 16 Feb 2012 16:28:07 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org From sylvain.lombart at gmail.com Fri Feb 17 06:51:48 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Fri, 17 Feb 2012 14:51:48 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows Message-ID: Hello all, I want to use RXTX library to read/write on a USB serial port on Mac OS 10.6. I'm using this simple code : public void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); CommPort commPort = portIdentifier.open("TEST", 2000); SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); // Open streams InputStream in = serialPort.getInputStream(); OutputStream out = serialPort.getOutputStream(); System.out.println("Stream opened on " + portName); // Send command byte[] cmd = {0x02, 0x3F, 0x0D}; out.write(cmd); System.out.println("Sent"); // Prepare reading byte[] back = new byte[1]; back[0] = 0; int i = 0; System.out.println("Read..."); // Read while (i < 100) { in.read(back); System.out.println("Receive : " + back[0]); i++; } // Close streams and ports out.close(); in.close(); serialPort.close(); commPort.close(); } Under Windows, this code send me "Receive : X" 100 times, where X is a good information. Under Mac OS 10.6, the script stops on "in.read(back)". I'm using RXTX 2.2 pre2. Thanks in advance ! Sylvain. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 07:17:40 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:17:40 +0000 Subject: [Rxtx] Licensing In-Reply-To: References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From sc1478 at att.com Fri Feb 17 07:32:23 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 14:32:23 +0000 Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Fri Feb 17 07:50:26 2012 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Fri, 17 Feb 2012 07:50:26 -0700 Subject: [Rxtx] Licensing Message-ID: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 08:42:34 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 15:42:34 +0000 Subject: [Rxtx] Licensing In-Reply-To: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> References: <20120217075026.8ef0e5b4a80cef441275a6330ffad77d.aa4f9865e7.wbe@email13.secureserver.net> Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F39F1@MOSTLS1MSGUSR9H.ITServices.sbc.com> understood. From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of jfh at greenhousepc.com Sent: Friday, February 17, 2012 8:50 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing Steven, I know, but I'm not as worried about that as I am about any of the code being licensed under the GPL. If it were GPL'd code, I'd remove it =immediately=. There are enough instances where the "Lesser GPL", "Library GLP" and "LGPL" are all the same that any attempt to claim he =really= meant for RXTX to be "GPL"'d code would fail. -- Julie Haugh Senior Design Engineer greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype -------- Original Message -------- Subject: Re: [Rxtx] Licensing From: "COHEN, STEVEN M" > Date: Fri, February 17, 2012 8:32 am To: "rxtx at qbang.org" > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml Thus the source code refers to one version of this license and the web page refers to a different one. -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M Sent: Friday, February 17, 2012 8:18 AM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Trent It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). Source code: /*------------------------------------------------------------------------- | rxtx is a native interface to serial ports in java. | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk | | This library is free software; you can redistribute it and/or | modify it under the terms of the GNU Library General Public | License as published by the Free Software Foundation; either | version 2 of the License, or (at your option) any later version. | | This library is distributed in the hope that it will be useful, | but WITHOUT ANY WARRANTY; without even the implied warranty of | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU | Library General Public License for more details. | | You should have received a copy of the GNU Library General Public | License along with this library; if not, write to the Free | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --------------------------------------------------------------------------*/ as opposed to http://rxtx.qbang.org/wiki/index.php/License : /*------------------------------------------------------------------------- | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. | RXTX is a native interface to serial ports in java. | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who | actually wrote it. See individual source files for more information. | | A copy of the LGPL v 2.1 may be found at | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is | here for your convenience. Note to self: read more carefully. Sorry for the confusion. Steve -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, February 16, 2012 5:28 PM To: rxtx at qbang.org Subject: Re: [Rxtx] Licensing On Thu, 16 Feb 2012, Trent Jarvi wrote: > > > On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: > >> I have read the licensing pages on RXTX >> (http://rxtx.qbang.org/wiki/index.php/License and >> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >> downloaded from the same site >> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >> license is the GPL, not the LGPL. For example, the README file within >> that zip and many if not all of the files in the source directory indicate >> a GPL license. >> >> Can someone from the RXTX comment on the inconsistency? Which is >> authoritative? >> > > Hi Steve, > > The license is LGPL 2.1 with an exception for users of Sun's CommAPI which > allows linking over a 'controlled interface' which was recommended and > approved by a few companies. > > http://users.frii.com/jarvi/rxtx/license.html > > There are no plans for making any changes to the license. > > I'll try to find and correct any inconsistancy you found. > I can't find any reference to rxtx being licensed under the GPL. If you have more information, I'll look into it. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc1478 at att.com Fri Feb 17 14:50:28 2012 From: sc1478 at att.com (COHEN, STEVEN M) Date: Fri, 17 Feb 2012 21:50:28 +0000 Subject: [Rxtx] Can anyone tell me where to get javax comm 2.0.3 jar? Message-ID: <2A3405378AE6F24EA26ECBA87E42CEBB126F3B7F@MOSTLS1MSGUSR9H.ITServices.sbc.com> All the links on your site into Oracle lead nowhere. The jar does not appear to be available. Looks like Oracle has buried it, intentionally or otherwise. Does anyone know where it may be found? Thanks, Steve Cohen From tjarvi at qbang.org Sat Feb 18 08:09:15 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 08:09:15 -0700 (MST) Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: On Fri, 17 Feb 2012, Sylvain Lombart wrote: > Hello all, > > I want to use RXTX library to read/write on a USB serial port on Mac OS > 10.6. I'm using this simple code : > > public void connect ( String portName ) throws Exception > ??? { > > ??????? CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > ??????? CommPort commPort = portIdentifier.open("TEST", 2000); > > ??????? SerialPort serialPort = (SerialPort) commPort; > ??????? serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > > ??????? // Open streams > ??????? InputStream in = serialPort.getInputStream(); > ??????? OutputStream out = serialPort.getOutputStream(); > ??????? System.out.println("Stream opened on " + portName); > > ??????? // Send command > ??????? byte[] cmd = {0x02, 0x3F, 0x0D}; > ??????? out.write(cmd); > ??????? System.out.println("Sent"); > > ??????? // Prepare reading > ??????? byte[] back = new byte[1]; > ??????? back[0] = 0; > ??????? int i = 0; > ??????? System.out.println("Read..."); > > ??????? // Read > ??????? while (i < 100) { > > ??????????? in.read(back); > ??????????? System.out.println("Receive : " + back[0]); > ??????????? i++; > > ??????? } > > ??????? // Close streams and ports > ??????? out.close(); > ??????? in.close(); > ??????? serialPort.close(); > ??????? commPort.close(); > > ??? } > > Under Windows, this code send me "Receive : X"? 100 times, where X is a > good information. > Under Mac OS 10.6, the script stops on "in.read(back)". > Hi Sylvain, The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. It is possible to poll for bytesAvailable or listen for the bytes available event. As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sat Feb 18 11:25:29 2012 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 18 Feb 2012 12:25:29 -0600 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Also, based on the logic of your application, you are not checking the return value of in.read(back). It doesn't have to return 1, it might return 0. Check the return value on windows to make sure you are not just doing a non-blocking read and not getting any data back. Gregg Wonderly On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > >> Hello all, >> I want to use RXTX library to read/write on a USB serial port on Mac OS >> 10.6. I'm using this simple code : >> public void connect ( String portName ) throws Exception >> { >> CommPortIdentifier portIdentifier = >> CommPortIdentifier.getPortIdentifier(portName); >> CommPort commPort = portIdentifier.open("TEST", 2000); >> SerialPort serialPort = (SerialPort) commPort; >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); >> // Open streams >> InputStream in = serialPort.getInputStream(); >> OutputStream out = serialPort.getOutputStream(); >> System.out.println("Stream opened on " + portName); >> // Send command >> byte[] cmd = {0x02, 0x3F, 0x0D}; >> out.write(cmd); >> System.out.println("Sent"); >> // Prepare reading >> byte[] back = new byte[1]; >> back[0] = 0; >> int i = 0; >> System.out.println("Read..."); >> // Read >> while (i < 100) { >> in.read(back); >> System.out.println("Receive : " + back[0]); >> i++; >> } >> // Close streams and ports >> out.close(); >> in.close(); >> serialPort.close(); >> commPort.close(); >> } >> Under Windows, this code send me "Receive : X" 100 times, where X is a >> good information. >> Under Mac OS 10.6, the script stops on "in.read(back)". >> > > Hi Sylvain, > > The while loop will depend upon the behavior of the underlying OS. If the read returns quickly, the loop will race and slow down other activities as it does so. You can try to specify some control over the behavior with the timeout and threshold values. > > It is possible to poll for bytesAvailable or listen for the bytes available event. > > As a crude hack, sleeping for a few milliseconds prior to polling with reads in your code should avoid the problem. > > -- > Trent Jarvi > tjarvi at qbang.org_______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Feb 18 21:30:50 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 18 Feb 2012 21:30:50 -0700 (MST) Subject: [Rxtx] Licensing In-Reply-To: <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> References: <2A3405378AE6F24EA26ECBA87E42CEBB126F289C@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F3988@MOSTLS1MSGUSR9H.ITServices.sbc.com> <2A3405378AE6F24EA26ECBA87E42CEBB126F39BB@MOSTLS1MSGUSR9H.ITServices.sbc.com> Message-ID: Just to close the loop on this. The V2.0 terminology was indeed Library vs Lesser used in 2.1. The license optionally allows transition to newer versions by people recieving copies so I'm not too concerned about that on a per file basis but will fix it. On Fri, 17 Feb 2012, COHEN, STEVEN M wrote: > Actually, there IS a small bit of inconsistency here. As of v. 2.1, this license became known as the "GNU Lesser General Public License", as opposed to "GNU Library General Public License" which was its name for previous versions. > > "The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances." -- http://www.oss-watch.ac.uk/resources/lgpl.xml > > Thus the source code refers to one version of this license and the web page refers to a different one. > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of COHEN, STEVEN M > Sent: Friday, February 17, 2012 8:18 AM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Trent > > It's my mistake. I saw "GNU Library General Public License" in the source file header and somehow missed the word "Library". There is no inconsistency. "GNU Library General Public License" IS the LGPL even though the abbreviation "LGPL" does not appear within the header information of each source file (as it does on the License web page). > > Source code: > /*------------------------------------------------------------------------- > | rxtx is a native interface to serial ports in java. > | Copyright 1997-2004 by Trent Jarvi taj at www.linux.org.uk > | > | This library is free software; you can redistribute it and/or > | modify it under the terms of the GNU Library General Public > | License as published by the Free Software Foundation; either > | version 2 of the License, or (at your option) any later version. > | > | This library is distributed in the hope that it will be useful, > | but WITHOUT ANY WARRANTY; without even the implied warranty of > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > | Library General Public License for more details. > | > | You should have received a copy of the GNU Library General Public > | License along with this library; if not, write to the Free > | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > --------------------------------------------------------------------------*/ > > as opposed to http://rxtx.qbang.org/wiki/index.php/License : > /*------------------------------------------------------------------------- > | RXTX License v 2.1 - LGPL v 2.1 + Linking Over Controlled Interface. > | RXTX is a native interface to serial ports in java. > | Copyright 1997-2007 by Trent Jarvi tjarvi at qbang.org and others who > | actually wrote it. See individual source files for more information. > | > | A copy of the LGPL v 2.1 may be found at > | http://www.gnu.org/licenses/lgpl.txt on March 4th 2007. A copy is > | here for your convenience. > > Note to self: read more carefully. > > Sorry for the confusion. > > Steve > > > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Thursday, February 16, 2012 5:28 PM > To: rxtx at qbang.org > Subject: Re: [Rxtx] Licensing > > > > On Thu, 16 Feb 2012, Trent Jarvi wrote: > >> >> >> On Thu, 16 Feb 2012, COHEN, STEVEN M wrote: >> >>> I have read the licensing pages on RXTX >>> (http://rxtx.qbang.org/wiki/index.php/License and >>> http://users.frii.com/jarvi/rxtx/license.html , both of which indicate an >>> LGPL license for RXTX). Yet, in looking at the code in rxtx-2.1-7r2.zip, >>> downloaded from the same site >>> http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7r2.zip I see places where the >>> license is the GPL, not the LGPL. For example, the README file within >>> that zip and many if not all of the files in the source directory indicate >>> a GPL license. >>> >>> Can someone from the RXTX comment on the inconsistency? Which is >>> authoritative? >>> >> >> Hi Steve, >> >> The license is LGPL 2.1 with an exception for users of Sun's CommAPI which >> allows linking over a 'controlled interface' which was recommended and >> approved by a few companies. >> >> http://users.frii.com/jarvi/rxtx/license.html >> >> There are no plans for making any changes to the license. >> >> I'll try to find and correct any inconsistancy you found. >> > > I can't find any reference to rxtx being licensed under the GPL. If you > have more information, I'll look into it. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sylvain.lombart at gmail.com Tue Feb 21 08:40:13 2012 From: sylvain.lombart at gmail.com (Sylvain Lombart) Date: Tue, 21 Feb 2012 16:40:13 +0100 Subject: [Rxtx] Problem read() blocking on Mac OSX 10.6, works under Windows In-Reply-To: References: Message-ID: Hi Trent & Gregg and thanks for your responses, You're right, this is an OS behaviour. My device have a battery, if the battery is down, device is not reachable, but COM port is active. I can send data, but i always receive 0. On Mac OS, i never receive 0, but it's a blocking read. I've set a second thread to implement a timeout, this problem can happend on Windows too with certain devices. Thanks again, Sylvain. Le 18 f?vrier 2012 19:25, Gregg Wonderly a ?crit : > Also, based on the logic of your application, you are not checking the > return value of in.read(back). It doesn't have to return 1, it might > return 0. Check the return value on windows to make sure you are not just > doing a non-blocking read and not getting any data back. > > Gregg Wonderly > > On Feb 18, 2012, at 9:09 AM, Trent Jarvi wrote: > > > > > > > On Fri, 17 Feb 2012, Sylvain Lombart wrote: > > > >> Hello all, > >> I want to use RXTX library to read/write on a USB serial port on Mac OS > >> 10.6. I'm using this simple code : > >> public void connect ( String portName ) throws Exception > >> { > >> CommPortIdentifier portIdentifier = > >> CommPortIdentifier.getPortIdentifier(portName); > >> CommPort commPort = portIdentifier.open("TEST", 2000); > >> SerialPort serialPort = (SerialPort) commPort; > >> serialPort.setSerialPortParams(1200, SerialPort.DATABITS_8, > >> SerialPort.STOPBITS_2, SerialPort.PARITY_NONE); > >> // Open streams > >> InputStream in = serialPort.getInputStream(); > >> OutputStream out = serialPort.getOutputStream(); > >> System.out.println("Stream opened on " + portName); > >> // Send command > >> byte[] cmd = {0x02, 0x3F, 0x0D}; > >> out.write(cmd); > >> System.out.println("Sent"); > >> // Prepare reading > >> byte[] back = new byte[1]; > >> back[0] = 0; > >> int i = 0; > >> System.out.println("Read..."); > >> // Read > >> while (i < 100) { > >> in.read(back); > >> System.out.println("Receive : " + back[0]); > >> i++; > >> } > >> // Close streams and ports > >> out.close(); > >> in.close(); > >> serialPort.close(); > >> commPort.close(); > >> } > >> Under Windows, this code send me "Receive : X" 100 times, where X is a > >> good information. > >> Under Mac OS 10.6, the script stops on "in.read(back)". > >> > > > > Hi Sylvain, > > > > The while loop will depend upon the behavior of the underlying OS. If > the read returns quickly, the loop will race and slow down other activities > as it does so. You can try to specify some control over the behavior with > the timeout and threshold values. > > > > It is possible to poll for bytesAvailable or listen for the bytes > available event. > > > > As a crude hack, sleeping for a few milliseconds prior to polling with > reads in your code should avoid the problem. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org_______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Howard at QtuTrains.com Wed Feb 29 15:17:43 2012 From: Howard at QtuTrains.com (QtuTrains) Date: Thu, 1 Mar 2012 11:17:43 +1300 Subject: [Rxtx] Raspberry Pi Message-ID: Sorry if this is a repeat question, but I cannot find any archives to search: Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. Howard From tjarvi at qbang.org Wed Feb 29 21:03:39 2012 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 29 Feb 2012 21:03:39 -0700 (MST) Subject: [Rxtx] Raspberry Pi In-Reply-To: References: Message-ID: On Thu, 1 Mar 2012, QtuTrains wrote: > Sorry if this is a repeat question, but I cannot find any archives to search: > > Are there any plans for a Raspberry Pi port. I suspect it might well be different to a generic ARM port. > I just tried compiling the c files with a fedora packaged cross compiler. The code appears to compile fine. If you have a link to the toolchain you think most people will use, we can make sure the autoconfiguration is working. Primarily this would be the gcc and libc used to build applications on the Pi R. -- Trent Jarvi tjarvi at qbang.org From m.rieke.mailing at googlemail.com Fri Feb 3 03:45:00 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 11:45:00 +0100 Subject: [Rxtx] Slow detection of serial ports Message-ID: Hi all, I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings works like a charm there. Now, I wanted to test my application on a Windows 7 64bit system and observed really long startup time of RXTX comm port detection. I am using the following code to search for open serial ports. It taks like 20 seconds to go through all registered ports. Anybody ever observed such behavior and knows how to fix it? Thanks in advance, Matthes private void initiliaze() throws Exception { boolean found = false; /* * the global ports of the OS */ Enumeration portList = CommPortIdentifier.getPortIdentifiers(); CommPortIdentifier portId = null; int c = 0; while (portList.hasMoreElements()) { c++; portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { if (portId.getName().equals(this.preferredPort)) { if (this.log.isInfoEnabled()) { this.log.info("Using port: "+this.preferredPort); } found = true; } try { this.openPorts.put(portId.getName(), (SerialPort) portId.open("MK Com Handler " + portId.getName(), 2000)); } catch (PortInUseException e) { } } } if (!found) { throw new Exception("Port " + this.preferredPort + " not found."); } /* * open the port */ this.serialPort = this.openPorts.get(this.preferredPort); if (this.serialPort == null) { this.log.warn("Could not open port "+ this.preferredPort); return; } this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); this.serialPort.notifyOnDataAvailable(true); this.serialPort.notifyOnOutputEmpty(false); this.inputStream = this.serialPort.getInputStream(); this.outputStream = this.serialPort.getOutputStream(); this.byteBuffer = new ByteArrayOutputStream(); this.serialPort.addEventListener(this); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.rieke.mailing at googlemail.com Fri Feb 3 04:42:17 2012 From: m.rieke.mailing at googlemail.com (Matthes R.) Date: Fri, 3 Feb 2012 12:42:17 +0100 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: I forgot to mention that the slow part is somewhere inside the CommPortIdentifier.getPortIdentifiers() method. Everything else works quite fast. Best, Matthes 2012/2/3 Matthes R. > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. > Everythings works like a charm there. Now, I wanted to test my application > on a Windows 7 64bit system and observed really long startup time of RXTX > comm port detection. I am using the following code to search for open > serial ports. It taks like 20 seconds to go through all registered ports. > Anybody ever observed such behavior and knows how to fix it? > > Thanks in advance, > Matthes > > private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info("Using port: "+this.preferredPort); > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), > 2000)); > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > this.serialPort.addEventListener(this); > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Fri Feb 3 05:05:58 2012 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 3 Feb 2012 14:05:58 +0200 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: Message-ID: Hi, I've got no direct answer to your question but in developing my PureJavaComm I came across the fact that trying to open 'busy' port in Windows can take up to nine seconds. And there was nothing I could do to work around that. This maybe related issue...or not. YMMV cheers Kusti On 2/3/12 13:42, "Matthes R." wrote: >I forgot to mention that the slow part is somewhere inside the >CommPortIdentifier.getPortIdentifiers() method. Everything else works >quite fast. >Best, >Matthes > >2012/2/3 Matthes R. > >Hi all, > >I am using RXTX 2.2pre1 for quite a while one Linux systems now. >Everythings works like a charm there. Now, I wanted to test my >application on a Windows 7 64bit system and observed really long startup >time of RXTX comm port detection. I am using the following code to search >for open serial ports. It taks like 20 seconds to go through all >registered ports. Anybody ever observed such behavior and knows how to >fix it? > >Thanks in advance, >Matthes > >private void initiliaze() throws Exception { > boolean found = false; > > /* > * the global ports of the OS > */ > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > CommPortIdentifier portId = null; > int c = 0; > while (portList.hasMoreElements()) { > c++; > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { > > if (portId.getName().equals(this.preferredPort)) { > if (this.log.isInfoEnabled()) { > this.log.info ("Using port: >"+this.preferredPort); > > } > found = true; > } > try { > this.openPorts.put(portId.getName(), (SerialPort) > portId.open("MK Com Handler " + portId.getName(), >2000)); > > } > catch (PortInUseException e) { > } > } > } > > if (!found) { > throw new Exception("Port " + this.preferredPort + " not found."); > > } > > /* > * open the port > */ > this.serialPort = this.openPorts.get(this.preferredPort); > if (this.serialPort == null) { > this.log.warn("Could not open port "+ this.preferredPort); > > return; > } > > this.serialPort.setSerialPortParams(57600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, > SerialPort.PARITY_NONE); > > this.serialPort.notifyOnDataAvailable(true); > > this.serialPort.notifyOnOutputEmpty(false); > > this.inputStream = this.serialPort.getInputStream(); > this.outputStream = this.serialPort.getOutputStream(); > > this.byteBuffer = new ByteArrayOutputStream(); > > > this.serialPort.addEventListener(this); >} > > > > > > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From msemtd at googlemail.com Fri Feb 3 06:29:28 2012 From: msemtd at googlemail.com (Michael Erskine) Date: Fri, 3 Feb 2012 13:29:28 +0000 Subject: [Rxtx] Slow detection of serial ports In-Reply-To: References: Message-ID: On 3 February 2012 10:45, Matthes R. wrote: > Hi all, > > I am using RXTX 2.2pre1 for quite a while one Linux systems now. Everythings > works like a charm there. Now, I wanted to test my application on a Windows > 7 64bit system and observed really long startup time of RXTX comm port > detection. I am using the following code to search for open serial ports. It > taks like 20 seconds to go through all registered ports. Anybody ever > observed such behavior and knows how to fix it? >From looking at your code you enumerate all the ports and only open the port that matches an exact name. Then all the ports identifiers are not retained. Why not just attempt to open the named port with the API call gnu.io.CommPortIdentifier.getPortIdentifier(String)? From gergg at cox.net Fri Feb 3 14:03:25 2012 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 3 Feb 2012 15:03:25 -0600 Subject: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 In-Reply-To: <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> References: <146B1557584B0B4DBD25ABAD45EF70F01FC5FD82@ALA-MBB.corp.ad.wrs.com> <1FA20E32-47C0-40A0-AED3-6572654C6EB3@rbr-global.com> <146B1557584B0B4DBD25ABAD45EF70F01FC68455@ALA-MBB.corp.ad.wrs.com> Message-ID: <2637DEBA-C612-4DC6-A739-96FCC67875B6@cox.net> I'd suggest that making an Eclipse only development environment is probably a little short sighted. I use netbeans my self, and I'd prefer to just have ant or something along those lines for a simple build. Maven might actually be a nice bridge between the two IDEs. Gregg Wonderly On Jan 31, 2012, at 3:03 AM, Oberhuber, Martin wrote: > This sounds great ! > > So here is my rough plan: > - Since the existing /rxtx-devel repository is not Eclipse friendly in its layout, I'd like to start a new /rxtx-eclipse repository for the administrative files needed to automatically build site (with .../plugins, /features, /releng siblings as we do these days at Eclipse) > - I would initially want to checkin prebuilt binaries into CVS and have just the Java part built by Jenkins / Maven / Tycho, which is state of the art at Eclipse these days > - Adding a step which builds binaries locally and replaces checked-out artifacts by the local build should be easy later on. > - I'm not yet sure about unittests, I wrote something minimal long ago ... extending this could also be considered once the basic infrastructure is up. > > Sounds good ? > > Thanks > Martin > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi > Sent: Monday, January 30, 2012 8:24 PM > To: rxtx at qbang.org > Cc: Qiangsheng Wang > Subject: Re: [Rxtx] Eclipse bundles and update site for rxtx-2.1-7r2 > > > > Hi Dr Johnson, > > We don't have a committers mail-list and many of those with commit access satisfied their personal requirements long ago. > > I would just start with Martin and I. As committers become active, we (or > you) can give them credentials. > > > > On Mon, 30 Jan 2012, Greg Johnson wrote: > >> Is there an address where I can write to the RXTX committers and give them >> the credentials for the Jenkins instance? >> Cheers, >> greg >> -- >> Greg Johnson, PhD >> President, RBR Ltd. >> greg.johnson at rbr-global.com >> +1 613 986 1621 (GMT-5, mobile) >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 1:18 PM, Trent Jarvi wrote: >> >> >> This would be great. I'd offer to help make this work. >> >> On Mon, 30 Jan 2012, Greg Johnson wrote: >> >> Dear Martin, We run Jenkins and could make an >> instance publicly available. >> >> We're sitting on a 10Mb fibre, so bandwidth >> shouldn't be an issue, and we >> >> could always limit the builds to the quieter >> periods in any case. >> >> Cheers, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> On 2012-01-30, at 7:58 AM, Oberhuber, Martin wrote: >> >> >> Hi Greg, >> >> >> >> The site is >> >> http://rxtx.qbang.org/eclipse >> >> and associated downloads are on >> >> http://rxtx.qbang.org/eclipse/downloads >> >> >> >> Interestingly, I updated that site just recently >> adding p2 metadata >> >> for Eclipse. When I created the site a couple years >> back I just took >> >> the rxtx-2.1-7r2 prebuilt binaries and put them >> into an OSGi bundle . >> >> I don't have a Mac so I can't judge whether what we >> currently have >> >> helps you or not. >> >> >> >> I'm actually interested in adding a recent >> (current) build to the >> >> site. We can build and test Windows and Linux at my >> company . if you >> >> could sign up to testing Mac, I'll be happy to >> "Eclipsify" your >> >> builds and upload them to the site. >> >> >> >> Ideally, we'd find some Continuous Integration >> factility (like >> >> Hudson, Jenkins, .) somewhere public for automated >> builds of the site >> >> . do you have an idea? >> >> >> >> Cheers >> >> Martin >> >> >> >> >> >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On >> >> Behalf Of Greg Johnson >> >> Sent: Sunday, January 29, 2012 7:24 PM >> >> To: rxtx at qbang.org >> >> Cc: Qiangsheng Wang >> >> Subject: [Rxtx] Eclipse bundles and update site for >> rxtx-2.1-7r2 >> >> >> >> Dear Martin and others, >> >> Is there a maintained set of RXTX eclipse plugins >> with an update >> >> site? We are particularly interested in the 64 bit >> OSX variant which >> >> appears necessary when using Java 6 on OSX as it >> does not have a 32 >> >> bit VM at all. >> >> >> >> Many thanks, >> >> greg >> >> -- >> >> Greg Johnson, PhD >> >> President, RBR Ltd. >> >> greg.johnson at rbr-global.com >> >> +1 613 986 1621 (GMT-5, mobile) >> >> +1 613 233 1621 (GMT-5, office) >> >> >> >> <~WRD000.jpg><~WRD000.jpg> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> [OS_Footer.jpg] [Oi_Footer.jpg] >> >> >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From ddevecchio at celestron.com Fri Feb 3 16:26:32 2012 From: ddevecchio at celestron.com (DERIK DEVECCHIO) Date: Fri, 3 Feb 2012 15:26:32 -0800 Subject: [Rx